User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Firefox/102.0

Steps to reproduce:

Run multiple (5-9) instances of Firefox in different profiles regularly

Actual results:

When one instance detects an update, it tries to install it, but there is apparently interference between it and the other instances.

Some instances wind up hanging when opening new tabs or windows. An update is now the first thing I check for when a page is too slow to load.

If one exits and restarts, it often takes several repetitions of that process to get a functional process back, the error about Firefox is already running often shows up, and sometimes works and sometimes doesn't, in which case Task Manager must be invoked to terminate processes.

Expected results:

Either it should work, or there should be an instant failure message telling that Firefox should be exited and restarted to get the update (or whatever the right steps are).

The Bugbug bot thinks this bug should belong to the 'Toolkit::Application Update' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Thanks for filing this.

Running so many instances for the same install is very edge casey, so I'm not surprised if there's issues here. I would love to get a screen capture when you get into this state to help me understand it a bit better.

A few other things may help a bit as well:

• Does the issue occur before one of the instances restarts for the update, or after?
• You say that it sometimes takes multiple restarts for an instance to work again -- is that per instance, or do they all work after the first one starts working?
• Your update process logs might be helpful here as well. If you could do the following, it would be great:

1. Navigate to about:support
2. Find the "Update Folder" entry and click "Open Folder".
3. Open the updates directory.
4. Inside, you should find files named last-update.log and backup-update.log. Attach these files to this bug.

• It would also be good to capture the the update service logs next time this occurs. You'll need to do this for every profile to do so:

1. Navigate to about:config.
2. Set app.update.log to true.

• When the issue occurs next, one of them should have some logs in the Browser Console, which you can find by:

1. Opening the Browser Console either with the hotkey Control+Shift+J (Command+Shift+J on macOS), or via Hamburger Menu->More Tools->Browser Console
   2.In the Filter textbox at the top, enter AUS:SVC to filter out everything except the update messages.

(In reply to bhearsum@mozilla.com (:bhearsum) from comment #2)

Thanks for filing this.

Running so many instances for the same install is very edge casey, so I'm not surprised if there's issues here. I would love to get a screen capture when you get into this state to help me understand it a bit better.

I'll do some screen shots next time I see the problem. It's been ongoing for a while. I'm sure there are not many that run as many concurrent instances on a regular basis.

A few other things may help a bit as well:

• Does the issue occur before one of the instances restarts for the update, or after?

I think before. My startup batch file starts all of the instances. Used to be I had started them in a loop with 10 seconds between each start, but Just recently, I started one instance early, and then the others in the 10 second delay loop, hoping that maybe the first instance would get the update done before the others start, but I don't really know what update process consists of, or whether that would help in any way or not. Since I'm not usually watching the computer during startup, I wouldn't click the restart button until all the instances are started, and wouldn't go looking for the restart button until some issue occurs (generally this one).

• You say that it sometimes takes multiple restarts for an instance to work again -- is that per instance, or do they all work after the first one starts working?

I think I've tried restarting a couple instances and got the errors multiple times per instance, but probably didn't try all of them multiple times.... once I encounter the issue and realize that it is probably this issue, then I try to reach a restart point in each instance, and shut them all down and restart them all. It is not clear to me which one is doing the update, generally. Is there a reliable way to tell? Sometimes I have concluded (rightly or wrongly I'm not sure) that the update actually happened, but that all the instances think it is still in progress. But that is usually after I have encountered the issue and restarted most or all of the instances, not being sure which one was doing the update, but the restarted instances still report that an update is in progress.

• Your update process logs might be helpful here as well. If you could do the following, it would be great:

1. Navigate to about:support
2. Find the "Update Folder" entry and click "Open Folder".
3. Open the updates directory.
4. Inside, you should find files named last-update.log and backup-update.log. Attach these files to this bug.

OK, good to know what to report. Is there a different log for each instance, or a shared log? Does the log tell which instance did the update? Is there even a way to discriminate among the instances? How are they named? Is there a way to correlate the instance with the information visible in Task Manager? I'd love to know which instance is doing the update, and shut all the others down...

• It would also be good to capture the the update service logs next time this occurs. You'll need to do this for every profile to do so:

1. Navigate to about:config.
2. Set app.update.log to true.

Presently this doesn't exist in any of my profiles. Is there still a user.js? Could it be set there? I presently don't have a user.js in any of my profiles, but could add that more easily by scripting than doing all the profiles manually. I assume this is a different log than the one you mention above?

• When the issue occurs next, one of them should have some logs in the Browser Console, which you can find by:

1. Opening the Browser Console either with the hotkey Control+Shift+J (Command+Shift+J on macOS), or via Hamburger Menu->More Tools->Browser Console
   2.In the Filter textbox at the top, enter AUS:SVC to filter out everything except the update messages.

And so I should report that log also to the bug.... just the filtered update messages? Or would some context before/around them also be useful?

(In reply to Glenn Linderman from comment #3)

(In reply to bhearsum@mozilla.com (:bhearsum) from comment #2)

A few other things may help a bit as well:

• Does the issue occur before one of the instances restarts for the update, or after?

I think before. My startup batch file starts all of the instances. Used to be I had started them in a loop with 10 seconds between each start, but Just recently, I started one instance early, and then the others in the 10 second delay loop, hoping that maybe the first instance would get the update done before the others start, but I don't really know what update process consists of, or whether that would help in any way or not. Since I'm not usually watching the computer during startup, I wouldn't click the restart button until all the instances are started, and wouldn't go looking for the restart button until some issue occurs (generally this one).

If I'm understanding correctly, your process is:

• Start one instance
• Wait 10 seconds
• Start the other instances
• Restart the first instance for an update when it tells you to

If that's right, I'm not surprised at all. Once one instance has updated Firefox, the other instances can no longer launch new processes (which they often do as part of opening new tabs). Adding a delay between the first and other instance may actually be making things worse -- we try to avoid starting the update at all if there's multiple instances running (to avoid this exact problem). We have ideas of how to fix this, but they've not been prioritized yet.

If I'm understanding correctly, your process is:

• Start one instance
• Wait 10 seconds
• Start the other instances
• Restart the first instance for an update when it tells you to

If that's right, I'm not surprised at all. Once one instance has updated Firefox, the other instances can no longer launch new processes (which they often do as part of opening new tabs). Adding a delay between the first and other instance may actually be making things worse -- we try to avoid starting the update at all if there's multiple instances running (to avoid this exact problem). We have ideas of how to fix this, but they've not been prioritized yet.

Well, not exactly. Before this week, I had a 10 second delay between each instance starting. This week, I changed it so the second instance has a 30 second delay, and the 3rd and one get 10.

From what you say, though, I'll try eliminating the delays and see how things go. I assume one instance will still try to do the downloads if a new version is ready? But then when would it ever get applied?

At the moment, I have 6 instances of Firefox running, all reporting that they are being updated by another instance...
Is there a way to discover this unknown instance?

(In reply to Glenn Linderman from comment #6)

At the moment, I have 6 instances of Firefox running, all reporting that they are being updated by another instance...
Is there a way to discover this unknown instance?

I should have mentioned that they all seem to be working, in spite of the update report.

(In reply to Glenn Linderman from comment #5)

From what you say, though, I'll try eliminating the delays and see how things go. I assume one instance will still try to do the downloads if a new version is ready? But then when would it ever get applied?

Yes, that's right - eliminating the delays should minimize or eliminate the possibility that you'll hit this race condition. (If you start another instance between the first Firefox instance beginning the update, but before it applies it, you end up in the state you're experiencing.)

(In reply to Glenn Linderman from comment #7)

(In reply to Glenn Linderman from comment #6)

At the moment, I have 6 instances of Firefox running, all reporting that they are being updated by another instance...
Is there a way to discover this unknown instance?

I should have mentioned that they all seem to be working, in spite of the update report.

This is a bit confusing - it will show up as long as another from the same install is running (even if it's not actively processing updates), because it's not safe to process updates with multiple instances from the same install running (as you've seen!). We try quite hard to avoid this (this bug has a lengthy comment if you're curious about how all of this works).

The tl;dr of all of this is that Firefox needs to have only one instance for an install to have it update.

@Glenn - I don't know if this is helpful to you, but I'm just going to jump in and make this pitch, just in case. Depending on what exactly you are using multiple profiles for, containers could be a better-supported alternative. This would let you side step the potential update problems currently caused by multiple simultaneous instances. The link gives a more complete explanation of what containers can do, but the quick version is that each container gets its own set of data (like cookies), which allows you to (for example) be logged into 2 different Gmail accounts in two different containers and have them not interfere with each other.

We are hoping to eventually solve the update problem more generally (this is tracked by Bug 1480452). But it may be quite some time before we are able to accomplish that.

Thanks much for the reply, Kirk, it gives me good information regarding containers, which I have only used for Facebook so far. But containers don't seem to meet all my needs. While off-topic for this issue, I'll list my needs, in case it inspires new features that would let me use containers instead of mulitple profiles, or in case there is even more function in containers than mentioned in the link.

1. Position different windows in different locations on the screen/desktop to separate usages to different locations.
2. Separate facebook from everything else.
3. Surprise! I actually run facebook in two separate profiles so that they can have different settings for default save directory….. and actually, a downloader extension in both profiles also knows about the corresponding default save directory.
4. Separate usage for different Google accounts (multi-account containers sound like they could solve this, but often this corresponds to 1 as well)
5. Each profile comes complete with its own home setting, which in most cases involves multiple tabs. While occasionally, I might want to start a new tab in a particular container without starting the home tabs, usually I would want to start the home tabs. And if I'm focused on a particular container, I would want its home icon to start only its home tabs, not all of them for all containers. So this probably would require one home setting for starting firefox, which might involve a technique for specifying which containers should be started besides which non-containerized tabs, and a different one for each container.
6. Separate ecommerce and ebanking from other uses. This includes wanting to separate a few saved passwords for those profiles from other profiles.

It isn't clear from what I read at the link that separate containers can preserve their own window positions, have separate saved account/passwords, separate default save directories, or separate home settings (to be used to open a container for the first time). I do have several profiles in overlapping window positions, that would probably be happy to live in the same window with different tab colors, if some of the other features existed. And some of them could probably be placed there now (when I have a chance, to enable me to gain experience with them) because they don't require the other features.

I have 20 different profiles at present, although 3 of them are for different versions of Firefox (development version, a nightly version, a saved portable version). The rest are used with the current release channel. I only start 5 when I boot up the computer (generally each morning), and others are used or not as events unfold during the day (and sometimes cause this issue to show up IIRC, or maybe don't work because this issue has already shown up, but wasn't noticed until the new profile was started).

Although the number of instances you run makes this more severe than most cases, ultimately this is the same root problem as bug 1480452.